21:32
4/11/2017

W piątek wieczorem w logach naszego serwera zauważyliśmy bardzo ciekawe wejścia na nasz stary artykuł poświęcony domenom w UTF-8. Referer wskazywał na pewną (obecnie niedostępną) stronę na Blogspocie, która już w URL-u zawierała inwektywy pod kierunkiem firmy Przelewy24. Zainteresowało nas to bardzo i stronę tę odwiedziliśmy. Był to początek bardzo ciekawych doświadczeń, które opisujemy w tym artykule. Jak widać, przeglądanie logów popłaca :)

16 błędów w kodzie wtyczek

Usunięty już post zawierał opis 16 błędów w kodzie pluginów, jakie firma Przelewy24 udostępnia swoim klientom, którzy korzystają z gotowych platform sklepów internetowych (np. Prestashop, Joomla).

Ktoś podpisujący się jako “Hackman”, przejrzał kod tych pluginów i wysnuł wniosek, że są (delikatnie mówiąc) niebezpieczne. Hackman ostro skrytykował Przelewy24, wskazując konkretne fragmenty w kilku pluginach, które powodowały możliwość przemycenia do silnika sklepowego (np. Prestashop) dowolnego zapytania SQL. W 2017 roku…

Czym takie coś może grozić? Potencjalny atakujący mógłby nie tylko “oznaczyć” swoje zamówienie jako zapłacone (chociaż go nie opłacił), ale w niektórych przypadkach byłby w stanie — z racji możliwości wykonywania dowolnego kodu SQL — całkowicie skasować bazę danych sklepu, albo ją wykraść.

Ale nie wszystkie z 16 błędów przedstawionych w poście były tak poważne jak chce je przedstawiać Hackman. Oto przykład błędu, który — powiedzmy sobie szczerze — przy SQL injection można potraktować jako nic groźnego.

Aby wykorzystać kolejny błąd polegający na ujawnieniu w kodzie URL do serwera developerskiego — co zresztą sam Hackman zauważa, wymagany jest dostęp do sieci wewnętrznej Przelewów24. A przecież mając taki dostęp można robić gorsze rzeczy. Trochę więc ten błąd naciągany.

I na koniec jeszcze jeden “błąd”, który też nie jest poważny, choć Hackman wskazuje, że pozyskane w taki sposób informacje można wykorzystać do dalszych ataków phishingowych (naszym zdaniem LinkedIn sprawdzi się lepiej — ale screena błędu umieszczamy, bo dzięki podanemu w nim linkowi dowiedzieliśmy się o całej sprawie ;)

Z 16 błędów opisanych przez Hackmana, tak naprawdę tylko 11 dotyczy wartych uwagi problemów wynikających jednak z 1 klasy podatności: braku odpowiedniej walidacji.

Co na to wszystko Przelewy24?

Zanim opowiemy o naszym kontakcie z przedstawicielami firmy, jeszcze raz zajrzyjmy do posta. Hackman twierdził w nim bowiem, że kontaktował się z firmą, próbując poinformować jej pracowników o błedzie, ale — tu cytat:

Tak, przekazywałem te informacje do szefa technicznego Przelewy24, ale mówił że jest weekend, temat mało istotny i poza tym ma wolne… Po weekendzie nie oddzwonił.

Taka reakcja jest niewyobrażalna i zasługuje na pełne potępienie. Chcieliśmy więc doznać jej na własnej skórze i jeszcze w piątek wieczorem skontaktowaliśmy się z Przelewy24. Okazało się, że firma już wie o tym incydencie bo kilkadziesiąt minut wcześniej została o nim poinformowana przez inne osoby widzące wpis na blogu. Przelewy24 zaprzeczyły jakoby Hackman się z nimi kontaktował przed publikacją na blogu, ale do sprawy podeszli poważnie i już rozpoczęli …poprawianie kodu pluginów i wystartowali z ostrzeganiem klientów.

Generalnie, bardzo często się zdarza, że kiedy do jakiejś firmy piszemy z informacją o błędzie, to firma ta twierdzi, że “błąd już poprawia”. Jesteśmy wiec na takie stwierdzenia dość wyczuleni.

Aby zweryfikować oficjalne stanowisko firmy, skontaktowaliśmy się mniej oficjalnie z osobą bliską źródłom dobrze poinformowanym. Osoba ta potwierdziła, że część programistów i zespołu handlowego już “obsługuje incydent”. I ta obsługa incydentu — choć błędy były beznadziejne — wcale beznadziejna nie była. Trzeba wręcz powiedzieć, że reakcja firmy jest tym co ją ratuje i na szczęście nie musieliśmy wierzyć naszemu kontaktowi na słowo. W Sobotę rano odebraliśmy bowiem na niebezpiecznikowej skrzynce kilna e-maili od naszych Czytelników, klientów P24 korzystających z dziurawych wtyczek. Okazuje się, że faktycznie w środku nocy P24 rozesłały ostrzegawczy mailing. Oto screen e-maila jaki podesłał nam Czytelnik Mateusz:

okraszając go takimi słowami:

Dzisiaj przed 4 rano wysłali mailing do wszystkich klientów, jak również DZWONIĄ do każdego aby usunął ich własna wtyczkę do Prestashop zatem błąd musi być bardzo poważny.

Inny z Czytelników podesłał nam namiar na grupę facebookową zrzeszającą polskich sprzedawców, na której pojawił się taki post:

Jak widać, firma przez noc wzięła się za łatanie a dodatkowo obdzwoniła wszystkich klientów, których problem dotyczył (a domyślamy się, że były ich setki). Taka postawa jest godna pochwały i chyba jest to jedno ze sprawniejszych obsłużeń incydentu, jakie widzieliśmy w Polsce w ostatnich latach. Takie szczęście w nieszczęściu.

Oświadczenie Przelewów24 w sprawie dziurawych wtyczek

W naszej korespondencji z Przelewy24 zapytaliśmy o to, ile dokładnie osób było potencjalnie narażonych na atak, bo korzystali z wtyczek z błędami, a także o to, dlaczego firma nie zareagowała na próbę kontaktu od hackmana. Oto odpowiedź nadesłana przez Michała Bzowego, Wiceprezesa Zarządu firmy Dialcom24:

Z wtyczek w których znajdowały się błędy korzystało niecałe 5% naszych klientów. Opisane problemy nie dotyczą zdecydowanej większości naszych klientów, którzy korzystają z naszego API do przetwarzania płatności.
Natychmiast po otrzymaniu informacji o błędach rozpoczęliśmy ich usuwanie. W nocy z piątku na sobotę poprawiliśmy kod wtyczek, a równolegle nasz zespół handlowy kontaktował się z klientami, prosząc o czasowe wyłączenie wtyczki do momentu otrzymania nowej wersji.
Chcę zaznaczyć, że informacja o błędach we wtyczkach nie dotarła do nas od osoby, która jest autorem wspomnianego artykułu. Nie możemy potwierdzić, aby “hackman” lub ktokolwiek inny kontaktował się z kimkolwiek z naszego zespołu przed publikacją opisów błędów w internecie. Bolejemy nad tym, bo zawsze staramy się błyskawicznie reagować na zgłaszane nam problemy dotyczące naszego oprogramowania i nigdy nie chowamy głowy w piasek.

Przelewy zapytaliśmy też o to, czy ten sam zespół programistów pracuje nad kodem wtyczek co nad kodem API. I na szczęście uzyskaliśmy odpowiedź “nie”. W przypadku Przelewów24 serwis transakcyjny, który jest objęty normą PCI DSS, jest regularnie testowany (bo musi być, gdyż przetwarza dane kartowe). Ale wtyczki najwyraźniej nie podlegały takiemu obowiązku.

Kogo faktycznie dotyczył błąd?

A więc podsumowując, ustalmy co tak naprawdę się wydarzyło i jak poważny jest ten problem.

  • Z Przelewy24 można zintegrować się poprzez API (programista po stronie sklepu sam implementuje jego obsługę) lub poprzez wtyczki przygotowane na różne platformy sklepowe przez programistów Przelewów24 (tę drogę wybrało tylko 5% klientów).

    W tych wtyczkach (nie w API) znajdowało się kilka poważnych błędów, które pozwalały na odpalenie dowolnego kodu SQL po stronie silnika sklepu, a co za tym idzie nieautoryzowaną modyfikację danych, która mogła doprowadzić do zakupów za darmo albo kradzieży bazy danych ze sklepu (lub jej zniszczenie). Tu trzeba podkreślić, że API i wtyczki to 2 osobne projekty Przelewów24, które nie współdzielą ze sobą kodu i które są tworzone przez odrębne zespoły programistów.

  • Ktoś ukrywający się pod nickiem “hackman” te odnalazł błędy we wtyczkach i ponoć próbował dać znać Przelewom24, ale twierdzi, że został rzekomo zignorowany. To go zdenerwowało i opublikował post z opisem 16 błędów (z czego tylko 11 dotyczy SQL injectoin, a reszta to mało istotne informacje na temat cyklu rozwoju oprogramowania w Przelewy24). Tu warto zaznaczyć, że Przelewy24 oficjalnie zaprzeczają, jakoby ktoś się z nimi przed ujawnieniem błędów publicznie przez Hackmana kontaktował w tej sprawie. Nasze kontakty zaznajomione ze sprawą nieoficjalnie poinformowały nas, że telefony i skrzynki e-mail pracowników firmy zostały przeszukane pod kątem próby kontaktu, ale śladów takiego kontaktu nie odnaleziono. Tajemniczy Hackman, o ile opisy błędów podpiera twardymi dowodami, to próbie kontaktu, która miała być przyczyną publikacji jego wpisu, poświęca jedno zdanie i nie podpiera żadnym dowodem. Hmm…
  • Błędy dotyczą wtyczek dla Prestashop, Zencart, Virtuemart, Opencart, WordPress i Joomla, ale Hackman zaznacza, że tylko tym wtyczkom się przyglądał i robił to dość pobieżnie. Błędów może być więcej. Zalecamy więc aby każdą wtyczkę autorstwa Przelewów24 w wersji sprzed 4. listopada traktować jako potencjalnie groźną i szybko ją wyłączyć.
  • Pracownicy Przelewy24 zostali ściągnięci na noc do firmy. Programiści poprawiali wtyczki a handlowcy informowali klientów firmy, którzy korzystali z podatnych wtyczek kontaktując się z nimi zarówno e-mailowo i telefonicznie.

Dotpay też ma problemy?

Na koniec warto wyciągnąć z posta Hackmana jeszcze jedną ciekawostkę. W jednym ze zdań, twierdzi on, że przyjrzał się też innemu pośrednikowi w płatnościach – firmie Dotpay. Nie precyzuje co konkretnie oglądał, ale twierdzi, że:

Mam już całą ich bazę zawierającą dane Merchantów, prowizji itd, ale nie jest na sprzedaż.

Post Hackmana tajemniczo znika kilkanaście godzin po publikacji

Postać Hackmana jest ciekawa jeszcze z 2 powodów. Jego post jest pełny emocji i trochę niepotrzebnie zbyt wulgarny. Pojawiają się groźby i obrażanie (próbkę widzicie na screenie powyżej), co Hackmana — w przeciwieństwie do publikacji informacji o błędach — naraża na kłopoty prawne. Podobnie niezręczne dla Hackmana może być wytłumaczenie się z wyznania, że “wbił się także do firmy HR“.

Zastanawiamy się, dlaczego tego posta nie napisał w bardziej stonowany sposób — zwłaszcza, że (co widać po opisie błędów) jest to niewątpliwie inteligentny człowiek. I być może sam Hackman się nad tym samym zastanowił po publikacji, bo jego artykuł tajemniczo zniknął z bloga.

Jedyna sprzeczność w publikacji Hackman dotyczy jego narzekania na to, że nie uzyskał odpowiedzi od Przelewów24, a Przelewy natomiast twierdzą, że żadnej próby kontaktu nie było. Hackman nie przedstawił żadnych dowodów na próbę kontaktu i jest to trochę to dziwne, bo resztę tez w swoim poście podpiera konkretnymi dowodami.

Zastanawiające jest też to, że osoba, która wydaje się mieć wysoką wiedzę i doświadczenie z zakresu bezpieczeństwa poprzestała na jednej próbie kontaktu z jedną osobą, kiedy w swoim poście zdradziła, że poznała co najmniej kilkanaście adresów e-mail innych pracowników Przelewów24 bezpośrednio odpowiedzialnych za projekty, których dotyczyły błedy. Dlaczego z tymi osobami Hackman nie podjął próby kontaktu? Trochę to podejrzane… Czyżby ktoś chciał celowo zaszkodzić Przelewom24? A jeśli tak, to dlaczego?

Korzystałem z Przelewy 24 — co robić, jak żyć?

W 95% przypadków nic nie musisz robić. Bo to nie serwis transakcyjny Przelewów24 zawierał błędy, błędy były we wtyczce z której korzystało 5% klientów Przelewów24 (raczej mniejsze sklepy, z tego co udało nam się wywnioskować). API a wtyczki to 2 różne projekty Przelewy24, które nie współdzielą kodu i są realizowane przez osobne zespoły.

  • Jeśli jesteś klientem Przelewy24, który zintegrował się po API, to w API błędy nie zostały odnalezione (co nie oznacza, że w Twoim kodzie integrującym API ich nie ma — na wszelki wypadek go sprawdź. Jakby co, możemy pomóc.).
  • Jeśli jesteś klientem Przelewy24, który zintegrował się przez wtyczkę, to pewnie już dostałeś od Przelewów e-maila, a nawet telefon, a w niektórych przypadkach także kod poprawionej wtyczki. Wgraj ją. A jeśli nie ma jeszcze poprawki dla Twojej wtyczki, wyłącz tę, którą obecnie używasz. Programiści Przelewów w pierwszej kolejności poprawiali kod tych wtyczek, które są używane przez największą liczbę klientów.
  • Jeśli jesteś użytkownikiem Przelewy24, który kupował coś w internecie korzystając z tego systemu, to nic nie musisz robić. Istnieje co prawda ryzyko, że jeśli korzystałeś ze sklepów internetowych, które z Przelewy24 zintegrowały się przez wtyczkę, a nie API, to ktoś mógł podejrzeć Twoje dane (albo opłacić Ci nieopłacone zamówienie — ale na to nie będziesz narzekać ;). Na chwilę obecną jednak żadne tego typu działania nie są nam znane i wygląda na to, że błędów nikt nie wykorzystał do kradzieży danych (a przynajmniej nie na masową skalę, bo wtedy zapewne jakieś echa działań takiego przestępcy by do nas dotarły na redakcyjną skrzynkę). Tak czy inaczej, warto dmuchnąć na zimne i jak zwykle w przypadkach cienia podejrzenia wycieku, zmienić swoje hasła na unikatowe, a tam gdzie się da wdrożyć dwuetapowe uwierzytelnienie.

 

Słaby kod, ale doskonała reakcja na incydent

Podsumowując, był to ciężki weekend dla programistów Przelewy24. Niech ta sytuacja będzie przestrogą także dla innych firm, które realizują równocześnie kilka projektów i marginalizują znaczenie tych wykorzystywanych przez mniejszą liczbę klientów. Na podstawie tego incydentu pięknie widać, jak ważne jest aby regularnie testować nie tylko główne projekty, ale i poboczne elementy systemu. I jak bolesne może być rozwijanie kodu przez kilku programistów, z których każdy dba o jego fragment i “nie widzi całości” a na dodatek każdy ma inny styl programowania, co dodatkowo może “zaciemniać” problemy powstające w kodzie. Hackmen pokazał, że takie “security by obscurity” to nie jest najlepsze podejście.

Wszystkim “nieautoryzowanym pentesterom” chcielibyśmy na koniec przypomnieć o naszym poście z cyklu Poniedziałek z Prawnikiem. Aby nie narażać się na odpowiedzialność warto zadbać o odpowiednie przekazanie swoich znalezisk (no chyba, że ktoś z góry zakłada, że chce komuś zaszkodzić). Wystrzegajcie się stylu Hackmana, bo za odnalezione błędy raczej nikt nie będzie mieć do Was pretensji, to obrażanie i grożenie może się już źle skończyć.

Tak się składa, że na nadchodzacej konferencji Security Pwning, będziemy mieli prelekcje na temat aspektów prawnych w życiu pentestera. Zapraszamy!

Ułatw innym zgłaszanie błędów w Twoim kodzie!

Aby ułatwić kontakt osób, które chcą zaraportować błąd bezpieczeństwa niedawno zaproponowano nowy “standard” security.txt. Wystarczy na swojej stronie wystawić plik tekstowy o nazwie security.txt, który będzie zawierać adres e-mail pod który badacze mogą zgłaszać problemy z bezpieczeństwem dotyczącym serwisu i klucz GPG, którym mogą zaszyfrować informacje. Przykład takiego pliku znajdziecie u nas: https://niebezpiecznik.pl/security.txt — polecamy wdrożyć u siebie.

Kończąc, pamiętajcie aby zawsze samodzielnie, albo z pomocą specjalistów, sprawdzać “wtyczki” i kod firm trzecich, jeśli integrujecie go ze swoim systemem.

Nikomu nie życzymy takich błędów w kodzie, jaki Przelewy24 miały w swoich pluginach, ale każdemu życzymy takiej reakcji na incydent, jaką przez noc z piątku na sobotę wykonał zespół Przelewów24.

PS. Za pomoc w przygotowaniu tego artykułu dziękujemy tajemniczym pracownikom zbliżonym do źródła. Dla pełnej przejrzystości informujemy, że niektórzy pracownicy Niebezpiecznika służbowo i prywatnie znają się z kilkoma osobami z firmy PayPro, która jest jedną z marek powiązanych z Przelewy24, ale nie oznacza to, że to właśnie te osoby udzielały nam nieoficjalnych informacji do tego artykułu.


Aktualizacja
Konkurencja Przelewów24, firma CashBill (na Niebezpieczniku często przywoływana z racji obsługi wszelkiej maści scamerów) już zdążyła “dowcipnie” nawiązać na swoim fanpage do incydentu i nieprzespanej nocny w ramach której pracownicy Przelewów24 informowali klientów o zagrożeniu. CashBill stwierdził, że ich wtyczki są bezpieczne. Hej, Hackman, challenge accepted? ;)

Przeczytaj także:

22 komentarzy

Dodaj komentarz
  1. System transakcyjny też nie jest wolny od błędów. Tytuły niektórych przelewów to “Array” (tak jakby konwersja tablicy na string w PHP) a w innych tytuł jest prawidłowy. Pomimo naszej skargi (nr zgłoszenia: Ticket#2017101777015367) bubel wisi dalej, ostatnie przelewy z takim tytułem mieliśmy 27.10.2017 r. Nie jest to może błąd krytyczny bo i tak płatników identyfikujemy po numerze SIMP a wpłaty rozliczamy na należności od najstarszych więc tytułu teoretycznie mogłoby nie być wcale. Wcześniej mieliśmy też problem z ustawieniem adresu do korespondencji (innego niż siedziby) tzn. po zatwierdzeniu formularza wracał stary adres. Adres zmieniliśmy po kontakcie z obsługą klienta. To wszystko świadczy o tym, że programiści niezbyt się przykładali do swojej pracy.

  2. Cóż, ja się kontaktowałem z BOKiem serwisu Przelewy24 i nie mam o nich zbyt dobrego zdania. Po pierwsze trzeba czekać nawet kilka dni na odpowiedź, a po drugie po informacji o błędzie w przykładowym kodzie stwierdzają nonszalancko, że to tylko przykład… ręce mi opadły, ale na szczęście problem został rozwiązany, więc zapewne kolejny programista natknie się na ten sam błąd co ja i tak będzie się kręcić kółeczko…

  3. Co do postu CashBill: nie śpi ktoś aby spać mógł ktoś! :)

  4. Nie, nie mam tej wtyczki. Nie jestem debilem

  5. Z artykułu i załączonej korespondencji wynika, że z wadliwej wtyczki PRESTASZOP korzystało 5% obsługiwanych sklepów a nie, że problem dotyczył 5% klientów ogólnie.

  6. Tyle czasu cisza była nie tylko o P24 ale w ogóle o płatnościach, aż nadchodzi dzień w którym PAYU wbija się na AliExpress oraz chce stamtąd wykopać P24 – i nagle wyskakuje spod ziemi jakiś Hackman i publikuje krytyczne podatności. Przypadek? Taaa… (sorry, niewierzący jestem).

  7. Nie uważam aby reakcja tego hakera nyła w najmniejszym stopniu wulgarna; dla mnie to właśnie ona jest dowodem jaki syf mają w kodzie. Osoba o słuchu absolutnym czuje ból gdy słyszy nieczyste dźwięki. BTW mówicie że ktoś chce zrobić na złość przelewom24 ale to przecież klienci przelewów będą mieli przechlapane gdy w systemie płatności będzie opłacone w 100% a firma dostanie 1zł i ciekawe do kogo zapuka GIODO gdy ktoś mniej wulgarny od Hackmana skopiuje bazę klientów sklepu i wystawi ją na sprzedaż

  8. W artykule zadziwia mnie karcący ton w stosunku do “Hackmana”, towarzyszący pochwalnym peanom na cześć p24. Doskonała reakcja? Most się zawalił i od razu wysłano karetkę?… Ani przez chwilę nie założyliście, że przedstawiciel p24 może zwyczajnie łgać w kwestii kontaktu. Po drugie – gdzie tu są groźby? To, że gość mówi, że programistom należałoby zafundować kastrację, to nie groźba tylko hiperbola.

  9. Hakermanowi brakuje kominiarki. Mamy małe szczęście w nieszczęściu – baza nie jest na sprzedaż. pozostaje wierzyć i trzymać kciuki, by nigdy nie była. W końcu powiedziano to w czasie teraźniejszym. A jakość kodu – w prawie każdej firmie piszą popelinę. Dlaczego? Bo nie ma pieniędzy na jakość i produkty wypuszcza się tak szybko by klienci byli zadowoleni lub tak szybko by konkurencja była niezadowolona.

  10. Z 16 błędów opisanych przez Hackmana, tak naprawdę tylko 11 dotyczy wartych uwagi problemów wynikających jednak z 1 klasy podatności: braku odpowiedniej walidacji.

    Tylko 11… ale tylko 1 wystarczy, żeby komuś napsuć krwi ;)

  11. P24 weszło też na Allegro, gdzie PayU miało monopol. To musiało zaboleć… Nie dziwne, że posuwają się do brudnych zagrań. Też nie wierzę w przypadki…

    • To P24 na Allegro to jakiś biurokratyczny niewypał. Trzeba tę funkcję dodatkowo aktywować, ponownie weryfikować rachunek bankowy (jakby nie wystarczała weryfikacja w PayU, które mogłoby zaświadczyć zgodność danych) oraz jeszcze wysyłać skany dowodu osobistego i dokumentów firmy. To wszystko niby pod przykrywką prania pieniędzy, finansowania terroryzmu ale przecież PayU to też legalny agent rozliczeniowy i tam jakoś da się przyjmować wpłaty bez takich procedur.

    • Mówisz że specjalnie wynajęto na zlecenie PayU miernych programistów żeby ci zrobili dla P24 wtyczki ? Działalność szpiegowska godna Rosji Radzieckiej :)

  12. Nie korzystam z P24 od momentu jak na 4 dni im zagineło 1500 zl które przelewałem. Kilkanaście telefonów na infolinie, nie potrafili podać informacji gdzie są pieniądze i kiedy zostaną przekazane na konto docelowe.
    Aktualnie, bardziej opłaca się płacić za Ekspres Elixir niz prowizje na P24.

  13. “tak naprawdę tylko 11 dotyczy wartych uwagi problemów”

    no 11 z 16 to naprawde jest TYLKO :)

  14. My natomiast nie otrzymaliśmy ani maila, ani telefonu.
    Korzystamy z wtyczki do woocommerce na WP.
    Brak podatności czy zapomnieli o nas?

  15. Dzięki wzorowej reakcji wyjdzie im to jeszcze na dobre:)

  16. Tak sobie myślę… tak potężne firmy i co?? Walczą o to, która zdobędzie większy rynek. Gdzie jest target? Jak to w korpo – wprost proporcjonalny do ludzkiej pazerności. Lepiej się nie wychylać, swoje robić i spokojnie wtedy można spać. Wtedy spokojny sen zależy głównie od Ciebie samego ;)

  17. Emocjonalny ton Hackmana może wskazywać na osobę, która wcześniej już przekonała się o kiepskiej jakości kodu wtyczek i próbowała zwrócić na niego uwagę grzecznie, ale została olana. Na przykład mógł to być programista, stażysta, praktykant, PM w P24 czy to w ‘zespole API’ czy też w ‘zespole wtyczek’, a swoje żale przekazał wspomnianemu dyrektorowi technicznemu nie oficjalnym mailem, ale osobiście lub mniej oficjalną drogą. Dodajmy do tego możliwość, że jest w tym ‘nowy’ i ciągle wierzący w to, że management da mu czas i środki na pisanie dopieszczonego kodu i dopadło go rozgoryczenie po zderzeniu z rzeczywistością. Albo od dawna wnosi o polepszenie jakości kodu wtyczek, i już go zmęczyło to, że wszyscy mówią ‘no będzie trzeba coś zrobić, ale to potem’ i o, mamy tekst pełen emocji, a tłumaczyło to by też dużą ilość konkretów w jego tekście.

  18. Jakiś rok temu przy okazji, instalacji ich wtyczki w sklepie OpenCart zadzwoniłem, że ich wtyczka nie ustawia statusów w sklepie – spławili mnie, że działa ok bo jeszcze się nikt nie skarżył i że to po mojej stronie problem.
    Wtyczkę sam poprawiłem, od tamtej pory omijam ich z daleka – jak widać słusznie.

    Podejście do klienta odrażające

  19. Przyznam, że nie spodziewałem się tak szybkiej reakcji -> mam tu na myśli usunięcie mojego bloga i konta w google, tak jakby nigdy nie istniało. Gratuluję kontaktów. Gratuluje profesjonalnego posprzątania sprawy pod dywan.

    Nie spodziewałem się, że można komuś usunąć konto google po dwóch dniach od publikacji + pierwszy wpis został usunięty po kilku godzinach i to jeszcze w weekend w środku nocy. Bez śladu, bez ostrzeżeń, bez powiadomień.

    Dopiero opublikowałem ok 1/3 materiału, jaki zgromadziłem na przelewy24, ale tym razem muszę poświęcić dłuższą chwilę, żeby to opublikować w miejcu, w którym na pewno mi tego nie zdejmą po kilku godzinach. Teraz nie mam czasu stawiać bezpiecznej infrastruktury, ale zbliżają się święta i luźniejsze weekendy a wtedy na pewno znajdę czas.

    Do usłyszenia.

    P.S. odnośnie cashbilla, to wcześniej go nie kojarzyłem, ale jak zobaczyłem ten post, to moją pierwszą myślą było, że ktoś im się włamał na fejsa, bo nikt kumaty nie publikuje takich textów. Szkoda mojego życia na ten serwis.

  20. P.S.2 Szef techniczny przelewów pojawił mi się na signalu, lepiej późno niż wcale.

Twój komentarz

Zamieszczając komentarz akceptujesz regulamin dodawania komentarzy. Przez moderację nie przejdą: wycieczki osobiste, komentarze nie na temat, wulgaryzmy.